home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 17536 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.4 KB  |  53 lines
  1. Path: news.belwue.de!uzwil!kuehl
  2. From: kuehl@uzwil.informatik.uni-konstanz.de (Dietmar Kuehl)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Optimizing lists etc
  5. Date: 16 Apr 1996 12:02:12 GMT
  6. Organization: FakultΣt fⁿr Mathematik und Informatik
  7. Message-ID: <4l0284$bua@news.BelWue.DE>
  8. References: <Dpn9xH.47v.0.-s@cs.vu.nl>
  9. Reply-To: dietmar.kuehl@uni-konstanz.de
  10. NNTP-Posting-Host: uzwil.informatik.uni-konstanz.de
  11. X-Newsreader: TIN [version 1.2 PL2]
  12.  
  13. Hi,
  14. Oscar Scholten (oscholt@cs.vu.nl) wrote:
  15. : Yet I was wondering if it is worth it to optimize them. Right now
  16. : the structures are pretty streight-forward, they all have some
  17. : search and sort options. The structures could become very large, 
  18. : and we do not want to waste any cpu-time on them.
  19.  
  20. Do optimization when it turns out that optimization is necessary.
  21. Locate the portions which need optimization by profiling not by one of
  22. the more common methods like "guessing", "knowning off-hand", "seeing",
  23. etc. If you have located one (of the normally few) portions of code,
  24. you might do optimizations there like hoisting checks out of loops,
  25. using better suited algorithms or data structures (e.g. an array might
  26. be better suited than a dynamically allocated list), inlining crucial
  27. functions, turning tail recursion into iteration etc. Get not be
  28. tempted to try optimizations by writing them in assembler: Most
  29. compilers are better in writing assembler code than most humans are.
  30. Although it is somewhat platform dependent, it is likely that you would
  31. end up with slower code if you write them in assembler yourself. There
  32. are only very few cases where assembler really pays off: If you are
  33. doing very fancy bitmanipulations which are directly supported by the
  34. assembler, there might be a speed gain which justifies writing
  35. assembler. Note, however, that assembler code is inherently harder to
  36. maintain or port to new platfroms.
  37.  
  38. : So is it possible to optimize a template using inline assembly etc ?
  39.  
  40. It probably is portable but it will be very compiler dependent and the
  41. necessary assembler might have to change with the next compiler
  42. release.
  43.  
  44. : And more important, what is the speed gain ?
  45.  
  46. On a newer architecture, i.e. a RISC cpu, you are good if your
  47. assembler is nearly as fast as the code generated by a compiler with
  48. optimization turned on...
  49. --
  50. dietmar.kuehl@uni-konstanz.de
  51. http://www.informatik.uni-konstanz.de/~kuehl/
  52. I am a realistic optimist - that's why I appear to be slightly pessimistic
  53.